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PERSONAL DATA INTERCHANGE 
by Jerry Michalski 


Zoe buys a new cellular phone. It’s light, snazzy-looking and offers two 
hours of talk time. Its dialing directory can hold 100 names and phone 
numbers but -- hold on -- entering the "L" in "Larry" means hitting the "5" 
key three times. Zoe decides she’ll ignore that feature. Later, while 
driving, she calls directory assistance, then juggles steering wheel, phone 
and paper to jot down the number...only to re-key it into the phone. The 
same happens when she calls her voicemail box. 


Phil, an inveterate electronics buff, buys Newton number 506 and rushes to 

show his friends his new toy. He starts demonstrating it by entering their 
names, and it takes him a while to realize that the Newton is interpreting 

their names as any roughly similar English words it can find. He switches 

to the built-in software keyboard. Then, with chagrin, he realizes he al- 

ready has all his friends’ names in his notebook computer’s personal infor- 
mation manager (and a few on his phone’s speed-dial buttons, and so on). 

He entered those numbers in a fit of excitement when he bought the PIM, and 
has been entering new ones ever since. 


Phil could wait for the Newton Connection Kit for Macintosh, due this month 
(a pe kit is due later this year), which would solve the file-conversion 
part of his problem. Or he could buy IntelliLink’s software (see page 14) 
and try to convert the data from his existing PIM into a format the Newton 
understands and ship it over the built-in AppleTalk connection. Or he 
could convince his friends to buy Newtons, enter their names, meet with him 
and zap them to him over the built-in infrared link. But what are the odds 
that they will all buy one, or that they will all like the Newton inter- 
face, let alone use it? If they decide 
on a different platform or none at all, 
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electronics devices need to replace frustrating, frequently performed tasks 
-- tasks so common that we ignore how often we do them, such as dictating 
our name, number and address when we leave a message, or handing a business 
card to a new acquaintance, or calling around to schedule and then resched- 
ule a meeting. 


Enter PDI 


This issue of Release 1.0 examines ways of making the exchange of business- 
card and calendar-event information more transparent; we call it personal 
data interchange (PDI). This time we don’t cover heavy-duty directory- or 
calendar-server synchronization, but rather what happens on desktops, hand- 
helds and phones. Like electronic data interchange (EDI, the computerized 
execution of transactions between companies), PDI is about machines mediat- 
ing what was once a paper or oral transaction -- but often without the rigor 
and security of EDI. Like EDI, PDI will require companies to agree on stan- 
dards for what data elements belong in what kind of envelope, and in some 
cases what is an appropriate response to a query. 


Unfortunately, echoing the term EDI also evokes a history of slow (albeit 
revolutionary) progress, of decades of painstaking negotiation through in- 
ternational standards bodies and of large, dedicated applications that ori- 
ginally ran only point-to-point (a management nightmare as the number of 
trading partners grows) or over expensive-to-implement X.400 networks. Al- 
though sharing resource and event information across heterogeneous platforms 
is complex and touches most corners of the computing and communications in- 
dustries, the core issues are relatively simple. If these issues can be 
solved, the resulting standards can act as building blocks for more sophis- 
ticated applications. Many of the people developing PDI solutions have been 
in the messaging or transactions businesses for a long time; hopefully, they 
can leverage the lessons they learned there to speed up this process. 


There is reason to move quickly. The sooner vendors agree on core features 
for PDI, the sooner their personal devices will collaborate and buyers will 
perceive value in them. If the value proposition to prospective buyers is 

enhancing action and communication based on personal information, then mak- 
ing the critical information simple to track and share is essential. 


MARKET DYNAMICS & SOCIAL ISSUES 


There’s more at stake here than growing the market for PDAs and other small 
platforms: Properly designed and broadly adopted PDI protocols will reveal 
and exploit the fundamental difference between the personal-electronics and 
desktop-computing markets. Rather than a winnowing-out of options in a ti- 
tanic battle over the mythical desktop ending in the victory of the medio- 
cre, the handheld market may successfully nourish many platforms of radi- 
cally different design and functionality. Finally, though it may take 30 
years, PDI protocols could change our Interaction with technology in a way 
that reintroduces -civility. More on that later. 


1 Discussion of similar needs motivated the Release 1.0 issues on unified 
messaging (12-92 and 1-93) and directory services (4-93), which were about 
requisite infrastructure; PDI’s focus is on the data we'd like to exchange. 
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A tug-of-war that has just begun will determine the nature of the personal 
electronics market. On one end of the rope are practical corporate consid- 
erations and the traditional software-industry market model; on the other 
end is human behavior. On the business side, corporations can benefit 
greatly from widespread adoption of messaging, group calendaring and docu- 
ment sharing. Mandating a single platform seems like a logical strategy: 
It can increase purchasing leverage, reduce training and support expenses 
and guarantee compatibility (well, more or less). Some corporate cultures 
value uniformity, and this strategy should work there.. 


Desktop-software vendors, eager to lock their corporate customers into pur- 
chasing only their products, are doing all they can from a product design, 
marketing and licensing perspective to achieve that goal. Suites are almost 
outselling individual products; buyers are evaluating a Notes middleware 
strategy vs. Windows for Workgroups (or At Work) on Chicago and NT, not just 
Ami Pro vs. Word for Windows. Corporate standards and large purchase orders 
are at stake. 


The personal is not the desktop 


Now we have EO, Zoomer and Newton -- others will follow. A new market of 
unknown size is opening up, and most corporations and vendors are dealing 
with it in much the way that they dealt with the desktop market: Corpora- 
tions are looking for a standard platform; vendors are looking for ways of 
gaining the kind of account control that was once IBM’s exclusive province. 


But human behavior has foiled many a marketing strategy in the past. PDI 
is, well, personal. Whom you talk to and what you do with your time are the 
most intimate decisions you make, so you won’t commit them to a computer 
system unless it feels just right (of course, there's always coercion). 
People’s tastes and preferences vary enough that no one approach or set of 
rules can make everyone happy. If Zoe is unhappy with her PIM, she won't 
update her electronic calendar regularly, which reduces the system's value 
to everyone. 


Also, PDAs, personal communicators and such will be cheap enough that indi- 
viduals will buy them, just as they often do calculators, Filofaxes and cel- 
lular phones. (And which one are they most particular about? The Filofax, 
with its personal information.) Corporations will have much less say over 
what PDA choices their employees make. Furthermore, although companies can 
mandate some standards outside their boundaries, as many did with EDI, they 
cannot dictate which PIM everyone will use. With consultants and alliances 
a growing part of business life, such connections are essential. 


A battered, well-thumbed personal address book may be ugly, but 
its contents are priceless. A phone company made great use of 
this fact in an ad campaign several years ago. 


Playing by the rules 


Ideally, the personal electronics market will be characterized by a profu- 
sion of devices and applications (often hard to separate from each other) 
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that mirrors the variety of preferences people have. Most people will use 
several devices, some of which have discrete operating systems, others of 
which don’t.2 


Tools will proliferate as people invent more ways of viewing and manipulat- 
ing information, as well as new roles for software to play in people's daily 
activities. Do you like plenty of help? Get software that takes an active 
interest in your activities, and tries to predict what you want to do next, 
such as Newton. Don’t like the invasiveness of being monitored? Get a less 
sophisticated tool, but be prepared to have to put things in the right place 
more often and catch duplicates yourself. Like software that looks just 
like its physical counterpart? Get a PIM with a strong physical metaphor, 
such as Lotus Organizer or Slate’s DayTimer. Think seeing your information 
in unusual new layouts might make you more productive? Try another. 


The platforms that fail will be those that don’t play by the connectivity 
rules, as well as those with lousy development environments. They will be 
less useful because they won’t collaborate effectively, and less valuable 
because they will lack a stream of third-party content and software. Micro- 
soft is likely to succeed regardless: It has enough market power to sway 
many developers and buyers, if not some behavior (why else would people 
still put up with eight-character filenames?). 


This vision of common servers and a proliferation of front ends has many im- 
plications for applications such as group calendaring and scheduling. For 
one thing, today’s offerings are monolithic: The front ends are designed to 
work only with their proprietary network-based back ends; hardly any of them 
have a client/server architecture. An evolution similar to e-mail is like- 
ly, where open servers are becoming popular, such as HP’s OpenMail, Micro- 
soft's MAPI (Messaging API) under the Windows Open Server Architecture, the 
Apple Open Collaboration Environment (AOCE) and the Internet. Users can 
then choose front ends that they prefer based on design and features, while 
retaining compatibility with the rest of the world. 


DESIGN CRITERIA FOR PDI 


In order to be broadly useful, PDI standards (can there ever be just one 
standard?) need to work with the widest possible variety of devices, ap- 
plications, transports and physical media. 


People will beam information directly from their PDA to someone else's over 
built-in infrared ports; they will use a PDA plugged between the phone and 
the phone outlet to autodial others (who may use the incoming information to 
decide whether to take the calls); they will dock their Duos and update the 
calendar server; they will send address or calendar queries in e-mail wrap- 
pers over wired and wireless data networks; and they will plug smart cards 
into rented devices. Above all, though, people will continue handing out 
business cards. 


2 Cellular and cordless phones have microcontrollers with embedded code, 
but not an OS. These devices can already hold names and numbers, and it 
isn’t too expensive to add an infrared port (see page 21). 
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Any device with enough memory to store numbers and autodial should be a can- 
didate platform for PDI. Some of them will have plentiful processing power 
and will host sophisticated communication engines such as Telescript (see 
page 18) and powerful front ends that resolve data conflicts and suggest 
solutions automatically; others will be so rudimentary that they will dis- 
card everything besides the name and number. But they should read the same 


data stream. 
Types of PDI Connectivity 


Person 
One Several 


Server (NT) 


f 


Same Windows pc Newton <d—pNewton 


” Companion Companion «@2Companion 
S (WinPad) 
Bes 
[a] 
k=] 
s 
[am 
Different Newton <@— Companion 
cellular 
cellular phone 
phone 
Task File synchronization Exchanges, transactions 
Priority Efficiency, transparency Privacy, reliability 
Preferred Remote: phone Remote: e-mail, phone 


Transport Near: cable, dock, infrared Near: infrared 


The chart above illustrates the different ways people will use PDI proto- 
cols. The upper-righthand quadrant is the simplest (it includes two people 
using the same device), and therefore the most developed: You can buy an 
Apple Newton or OZ-series Sharp Wizard today and exchange business-card data 
with other owners of the same machine. The lower lefthand quadrant (one 
person, many platforms) has some activity, such as IntelliLink’s gear to tle 
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Casio BOSS organizers to pcs; Seiko sells digital wristwatches that hold a 
Limited number of contacts, appointments and notes, and connect to Macs with 
a thin cable. 


But the upper-lefthand quadrant is the next frontier: Platform vendors are 
working to build architectures that encompass inexpensive, scant-memory de- 
vices as well as roomier, more traditional ones. More specifically, Micro- 
soft is working to make WinPad (er, Microsoft at Work for Handhelds, that 
is) synchronize easily with pes. The catch is that the pe has to run a ver- 
sion of the same software (see page 13). 


The the left and right sides represent different patterns of user behavior; 
the top and bottom halves, different marketing strategies. The left side is 
about people working with several of their own tools. Their want to have 
the information they need at hand when they really need it. To do that, 
they need a reliable way to keep the different elements synchronized. Indi- 
viduals are likely to carry one tool with them for a while, then dock or 
dial in to synchronize files with another piece of their distributed system. 
Some of their devices may have different operating systems (lower left). 


The right side is about several people exchanging information, and is char- 
acterized by smaller, more transactional events such as a single business 
card (vs. all the cards you collected on your last trip) or a meeting re- 
quest (vs. an update of all the meetings you scheduled while you were away 
today). Privacy and reliability are important here. Exchanging small mes- 
sages is simpler than synchronization, especially when the user is at hand 
to correct mistakes. 


Intra- and interplatform PDI 


The top half is about individual vendor strategies; the bottom, about cross- 
platform strategies and thus about standards and consortia, too. Again, 
large vendors’ top priority is getting the top half to work because they 
hope for critical mass on their own: for example, allowing people running 
different variants of Windows (NT, Modular, Chicago, vanilla) to synchronize 
and exchange files successfully. 


The bottom half is not only about pes talking to Newtons, but also about pcs 
talking to cellular phones, faxes and network services. The pce-phone con- 
versation hardly goes beyond autodialing today -- and that’s a command, not 
a data transfer to the phone. There are already some interesting telephony 
applications that involve personal information, mostly phone numbers, though 
they just scratch the surface of what is possible. 


For instance, some telcos now offer a directory-assistance service that will 
automatically dial the number you’ve looked up -- for a fee. The second 
unified messaging issue (Release 1.0, 1-93) describes AccessLine Technolo- 
gies, which offers software that prompts voicemail callers to key in their 
phone number ät the end of their messages. After listening to a message, 
the voicemail recipient can autodial the number by hitting the asterisk key. 
(The number can also be transmitted to a pager, which is more conventional.) 
Finally, for under $200 the DAK closeout electronics mail-order catalog 
will sell you a phone handset and two pocket electronic phone directories, 
all of which can exchange information via infrared links. Users still have 
to key names and numbers in with tiny alphabetic keypads, though. 
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The top half of the chart is rife with opportunities for third parties to 
create unique modules that enhance a user's experience with any devices that 
can hold or process PDI information. How about a "pack my briefcase" com- 
mand that instructs your PIM to download to your cellular phone the 50 names 
and numbers you've dialed most recently via an infrared transceiver attached 
to your pe’s serial port and a similar part built into your next phone? 
Their value (and everyone else's devices) will be higher if all parties 
agree to simple PDI formats. 


ere Social change: a return to civility 


In the 1800's and early 1900's, people customarily presented cal- 
ling cards when they visited a house or business. They used the 
calling cards to-seek admission to someone's presence. The tele- 
phone system, which has no such mechanism, dramatically changed 
that protocol (along with major demographic changes that reduced 
the number of intermediaries -- butlers and maids). Nowadays, 
people just call and interrupt (and some of us have secretaries), 


The effects on our private lives are extreme, yet subtle. You 
probably have a telephone on your night table, and you don’t 
think much about it. It can ring any time of day or night, and 
you have no way of knowing who is on the other end of the line. 
Yet you. do this, possibly in the hope that the caller will be 
someone you would like to talk to or in the dread that it will be 
a family emergency. But autodialers and other junk callers can 
disturb your peace at any time. To avoid them, you have to take 
active steps suchas unlisting your number, turning your phone’s 
ringer off (and remembering to turn it on again!) or screening 
calls with your answering machine. These are the kinds of prob- 
lems that PDI and filters can solve eventually. 


Caller ID is an early form of the solution, but it offers too 
little information, too late. It provides only the inbound num- 
- ber, which isn't very useful: An application still has to match 
it‘to a name. Most calls ‘don’t arrive with Caller ID informa- 
tion, anyway, and probably never will: Caller ID can’t identify 
callers using PBXes, or those calling from phones other than 
their own, or those in areas served by older switches, even if 
their state has. permitted (and their telco has delivered) the 
service. Regulation by state PUCs rather than the FCC has also 
hurt Caller ID. Finally, it only works within the so-called ad- 
vanced intelligent (wired phone) network. It’s not implemented 
in cellular, and it doesn’t translate to the e-mail world, which 
uses completely different addressing. Several entrepreneurs are 
suggesting-new methods that are completely independent and above 
Torr the phone network (see eCard, page 11). xe 


AE neons 
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BUSINESS CARDS 


Even if many vendors agree on standards and embed compatible infrared 
transceivers in their next-generation gadgets, it will still take five 
years for them to be commonplace, and maybe ten for them to be the norm 
(remember the day you realized you couldn’t do business any more without a 
fax?). Meanwhile, everyone carries paper business cards, and people spend 
countless hours typing in the information they contain. 


Although this problem has been around for a long time and a few products 
that can scan and read business cards have been on the market, principally 
in Asia, where pictographic writing has made scanners and imaging popular, 
their price/performance tradeoff has not attracted many buyers. Now, sev- 
eral startups are hitting the US market with business-card reading systems 
street priced around $300. The burst of activity in business-card OCR is 
partly due to the recent availability of inexpensive greyscale scanners. 
Black-and-white scanners often don’t provide enough resolution for accurate 
recognition; faxes, typically at 200 dpi resolution, are also poor fare for 
OCR engines (which is a shame, since you could fax your new business cards 
in from anywhere). 


Two companies, Cognitive Technology and Corex, are developing products that 
are similar in many respects. Both use scanners, which they drive automat- 
ically as the user feeds in business cards, one by one (separating multiple 
cards in a single scanned image is a wish-list feature). Both adjust con- 
trast and compensate for skewed images, and store the full card image for 
retrieval later. Then the software identifies regions on the business 
card, decides which ones to recognize, invokes an OCR (optical character 
recognition) engine, infers a mapping of recognized fields to expected 
fields and presents the results to the user. Both products run under Win- 
dows; neither is really a PIM, though Corex tries to be one, with its 
Rolodex-like user interface. 


Will Cuneiform read clay tablets? 


Cognitive Technologies is likely to field its card reader first. The com- 
pany was founded in 1990 by Russian Yefim Schukin and Denis Coleman, who 
co-founded C&E Software with Gordon Eubanks, which later acquired Symantec. 
Schukin, a theoretical physics Ph.D., emigrated to the US in 1973 and work- 
ed at the Stanford University AI lab for two years. After teaching and 
consulting, he formed a company around a team of Russian scientists in 1988 
to develop AI applications. Along with some US scientists, they form the 
core of Cognitive Technologies. They have developed image-processing algo- 
rithms and a character-recognition product called Cuneiform, which is the 
basis for Cognitive’s Business Card Reader (BCR). 


Cognitive is actively licensing its OCR engine. For example, Corel licens- 
ed an early version in 1992 for integration with CorelDraw; EDS has licens- 
ed it to recognize the preprinted text on preapproved GM credit-card appli- 
cations (they think it will be faster than coding and sorting them). Dex- 
tra and several other vendors of small, inexpensive vertical-format scan- 
ners, will bundle Cognitive’s software with their machines. And most visi- 
bly, Lotus has joined Cognitive in an agreement to link the product to 
Organizer, Lotus’ popular PIM. The agreement should give Cognitive much 


“more exposure and Organizer a valuable edge. 
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CuneiForm optionally uses greyscale scanning for better accuracy. It also 
uses adaptive thresholding, which helps compensate for colored backgrounds 
or faint writing and other business card irregularities. After the scan- 
ning and recognition process described above, the system displays the card 
image and recognized text on the same screen. Users can correct misrecog- 
nized or misplaced text by drawing rectangles around its image and dragging 
it to the right field; then the recognition engine tries again. (Where the 
spelling was fine but the field was wrong, our instinct was to grab the 
already-recognized text and move it to the correct field, but that's not 
the way the software works.) 


Long run, Schukin envisions his engine recognizing any printed matter -- 
from travel receipts to checks. Where once you might have photocopied the 
checks for your files, you can now recognize their contents and store the 
image at the same time. 


Corex: spelunkers of the modern age 


Boston-based Corex is starting with a similar offering, but has different 
long-term plans. It expects to ship an automatic business-card reading 
system called CardScan, which puts recognized data in a Rolodex-style 
format on a PC screen, by the end of 1993. In 1994, Corex will also offer 
another program called People & Places, which will help sift address in- 
formation from documents such as business letters and mailing lists. 


Corex licenses other vendors’ OCR engines. Instead of focusing on image- 
processing algorithms, it specializes in downstream tasks such as parsing 
and normalizing information, as well as synchronizing address books with 
other sources of address information. 


Where Cognitive is looking to expand into other paper sources of informa- 
tion such as receipts, Corex is looking to leverage its parsing and file- 
synchronization capabilities with sources already inside the computer net- 
work -- data mining/refining the address information. This should make it 
appealing to mobile computer users. It is also working on strong inter- 
operability with other pe applications. For example, a user writing a let- 
ter in a word processor will be able to type the recipient’s name, hit a 
People & Places icon, and insert the full mailing address automatically. 


Corex was founded in early 1993 by its president, Jonathan Stern, who pre- 
viously co-founded Rosh Intelligent Systems, a vendor of laptop-based ex- 
pert systems for field service organizations. He left Rosh in 1992, pur- 
suing ideas that led him inexorably to create Corex, which is privately 
funded. Chairman Rich Carpenter founded and ran Index Technology, which 
merged with Sage in 1991 to form Intersolv, one of the largest CASE tool 
providers. Prior to that, Carpenter co-founded CSC Index, a major IT man- 
agement consultancy. 


FORMATS AND PROTOCOLS 


The address on a standard US business letter usually conforms to a predict- 
able format, because the sender’s desire to get the letter to its destina- 
tion usually outweighs his compulsion to be on the aesthetic edge -- yet 
letter addresses are still tough to OCR (just ask any postal service!). 
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Business cards are far less predictable. They're a place where personali- 
ties manifest themselves, so they vary widely and include many creative and 
hard-to-recognize elements. Often the point is to stand out, which makes 
some cards undecipherable by even the best business-card reading systems. 


In the face of all this artistic expression of personality, the exchange of 
electronic business cards seems quite flat: People become records in a 
database; who wants that? The key to a functional and pervasive electronic 
standard is not only to keep the expressiveness, but perhaps to add new 
kinds of value as well as new forms of expression. The image of two people 
meeting and beaming business cards at each other seems a little funny be- 
cause it is a little funny. Luckily, that is not the central goal of PDI. 


When someone leaves a company, what’s the first thing he makes 
sure he takes? His Rolodex. 


One way that PDI outshines business cards is when you're not there in per- 
son, as in a telephone conversation or even a voicemail message (see Radish, 
page 22). Why dictate your name over and over, and still receive misspelled 
correspondence? A soft key on your phone can automatically send your data 
to the receiving device. 


Another benefit is giving people more ways of contacting you. For example, 
people often end their e-mail messages with a "signature." Naturally, these 
include other elements such as the person’s favorite quote or joke. But 
they also often have voice and fax numbers. Why can’t these automatically 
register in your address book, allowing you to reply in the manner most ap- 
propriate to your situation, without having to send an e-mail reply asking 
for a fax number? This information could also be part of the message en- 
velope, as with Telescript. 


Ingredients 


How much information should the standard define? The obvious place to start 
is with your name, physical and e-mail addresses and phone and fax numbers, 
yet even these are elements you may not want to give out all the time. You 
may also wear several hats at work, or consult for different companies, so 
flexible titles or multiple business cards would make sense. (Are you the 
president of a holding company or editor of a newsletter? Would you rather 
show yourself as a general partner in a ve firm or as the chairman of one of 
its troubled investments? What about your job as the parent of three kids 
and pillar of the community?) 


Once you get past the obvious, things get out of hand quickly, but express- 
iveness reigns. Your electronic business or calling card could include a 
digital signature or voiceprint for authentication, your office hours or a 
pointer to your electronic calendar, the company logo (and jingle!t), your 
picture (dressed appropriately for the season, of course), directions to 
your office or home (including a map), or even animation. People are put- 
ting all sorts of things in their X.500 directory entries, including their 
favorite drinks (see Release 1.0, 4-93). Finally, the card could include 
font, placement and display instructions. 
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Excuse me, do you have an eCard? 


Practical PDI requires that devices know what information to expect and what 
format it will be in. At GO (now EO), Telephony Architect Roland Alden has 
been working on a practical and forward-thinking format-and-protocol speci- 
fication called eCard, complete with a slot for a corporate logo and pronun- 
ciation guide (that’s Ma-'call-ski), if desired. His work on eCard was in- 
spired by noticing that many companies were working on ways to store and 
"beam" this information, but nobody was working to make it easily machine 
readable and ubiquitous. His draft eCard standard is available, and open 
for comments now (see Resources, page 25). 


Clearly, a standard such as eCard could find many uses and even affect be- 
haviors in ways such as the ones described earlier. As an example, Alden 
describes the following scenario. 


Think of a business card as a capability address. By giving you a 
business card I give you a certain kind of permission to reach me. I 
may give you a card with my home phone number for instance, and I may 
give a different card to someone else. More specifically, an eCard 
could contain an encrypted token. When you attempt to contact me, by 
phone, e-mail or whatever, you present the eCard I gave you. This 
identifies you to me, and my voicemail (or e-mail) system may take 
special action because it knows who you are. Thus, eCard exchange 
becomes an enabler for a form of cryptographically secure and authen- 
ticated Caller ID that exists in a protocol layer above "the network" 
and beyond the reach of regulatory agencies -- because we identify 
ourselves this way by mutual agreement. 


Providing identifying information outside the phone network sidesteps many 
of the political and practical problems with Caller ID and other network- 
based services. It also aids compatibility with other communication sys- 
tems such as e-mail, cellular and cable -- if they also adopt the standard. 


Where are the PIMs? 


It would seem that a discussion about personal information would somehow 
revolve around personal information managers, but PIMs haven’t done much 
about PDI. PIMs have historically fought for market share among individual 
users, a battle in which communication with other PIMs didn’t matter much. 
In fact, the easier it was for a user to transfer information from one PIM 
to the next, the more readily a customer base might migrate to a newer, 
fancier product. And two PIM users were not likely to have their pes handy 
and decide to pass information from one to the other. As recently as Au- 
gust 1992, the apathy toward inter-PIM cooperation inspired Traveling Soft- 
ware's president Mark Eppley to propose something he called the PIM Data 
Exchange (PDX) as a standard. PIM vendors showed no interest. 


Now, corporations are beginning to look at PIMs as important corporate 
software and handhelds with native PIM functions are hitting the market. 

As a result, PIM vendors are changing the way they compete, and are more 
willing to contemplate interchange. That still doesn’t mean they are lead- 
ing the way. It mostly means that they are making their products play on 
the corporate network by extending their personal calendaring features to 
group calendaring, for example. 
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PIM vendors may worry about conforming to a common data structure and ob- 
ject storage convention, which would require massive rewrites of their code 
and put them at a disadvantage. But PDI is less like Esperanto, where 
everyone has to switch over and live in the language for it to be effec- 
tive, than the protocols for a bank ATM card, which lets you go to citles 
in different countries; transact a simple, consistent piece of business; 
and receive funds in an appropriate currency. In PIM terms, PDI is about 
agreeing on what perspective to take on the data -- how to flatten the 
records for exchange -- not how to store or represent them locally. 


PIMs won't really have to adapt much, once they decide to play. Most al- 
ready have an "import" feature, which could be extended to deal with in- 
bound PDI traffic. The vendors could distinguish themselves from each 
other by offering more sophisticated software. For example, Arabesque's 
Ecco PIM has a feature called Shooter that runs in the background, places a 
small icon on the title bar of any Windows application running when Ecco is 
running and allows users to pass information to and from Ecco quickly. 
Arabesque could extend it to parse inbound PDI messages into Ecco’s phone- 
book section, and to export PDI messages to a variety of different target 
applications (maybe to a telephone via TAPI, Microsoft's Telephony API). 
Similarly, Rae Technology's Assist PIM, which has some clever built-in as- 
sistance, could help a user fill out incomplete fields or compose outbound 
PDI messages in the format appropriate for the medium used. 


Who's on first? 


PDI leadership is coming mostly from the new handheld-system vendors, which 
realize that smooth interchange is a key virtue and selling point. EO’s 
eCard (above) is a good example. PDI seems to be a second-generation fea- 
ture, though: The first priority is to get a stable device to market. 


Take the Newton, for example, which was designed from the ground up to be a 
communications-intensive machine. Out of the box, a Newton has built-in 
AppleTalk for easy connection to Macs. To communicate with pes, the Newton 
team licensed Traveling Software’s Universal Communications Object. For 
inter-Newton data "beaming," they licensed HP’s SIR (Serial Infrared) pro- 
tocol, which can also link to Sharp Wizards. Swimming in the Newton's Data 
Soup (the place it stores all information) is something called an Electron- 
ic Business Card. 


Just across the campus, another group has been working on the first release 
of Apple’s Open Collaboration Environment (AOCE). AOCE defines hierarchi- 
cal data structures called catalogs, which it uses for files (the Finder), 
for network resources (the Chooser) and for other things that used to have 
separate tools. It also has Info Cards -- lower-level structures that can 
hold data on people or other resources. Yet there is no clear path from 
Newton’s Electronic Business Cards to the AOCE Info Cards. 


Boomers vs. Busters? 


So it seems natural that the most work on PDI-style standards should come 
from a mobile platform coming up on its second major generation: PenPoint. 
We already mentioned Roland Alden’s work with eCard. In addition, EO’s 
Randy Stock and others have been working closely on PDI-style specifica- 
tions. They have been coordinating with General Magic’s George Fan, who is 
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in charge of defining Interplatform Content Formats (ICFs) that define what 
goes inside Telescript smart messages. Fan is also working closely with 
the Magic CAP team. 


Rather than a formal standard, ICF is a series of gentle guidelines defin- 
ing five major components of an ICF message. The first sets file formats 
for content elements (e.g., Jot for ink, MIDI for sounds). The second con- 
tains display hints. The third describes "vilewables" -- features such as 
buttons and text-input boxes whose display may vary by platform, but whose 
functionality is constant. The fourth defines data structures, such as ap- 
pointments, along with the attributes they require. The last segment holds 
the smarts: Telescript scripts that define what the message can do, such as 
negotiate and set an appointment (an example, page 19). Gateways will 
strip information from messages destined for non-Telescript platforms be- 
fore they leave the Telescript environment. 


Meanwhile, other vendors are attacking the problem from other directions. 
Microsoft and IntelliLink represent the alternative route, and go hand in 
hand, in a sense. At this time, their efforts are aimed principally at 
synchronization. 


MICROSOFT: FROM PORTHOLES TO PICTURE WINDOWS 


PDI touches many groups at Microsoft, from Microsoft Mail to Schedule+ and 
Microsoft At Work (which includes handhelds). Of these, the most active in 
PDI matters is WinPad, the only publicly announced Windows variant for 
handheld computers (Microsoft is trying to stamp out use of the term Win- 
Pad; we find it hard to avoid). It will be incarnated first by Compaq in 
1994. As opposed to Newton, which is positioned as a standalone platform, 
Microsoft’s handheld OS is a tightly coupled adjunct for Windows desktop 
systems. Microsoft is now deciding how to enhance it over time. 


The idea behind Microsoft's handheld platform is simple: Your personal in- 
formation already exists on your pc; why shouldn’t you be able to carry it 
around when you're away from your desk? Thus access to and synchronization 
with pe information is central to WinPad development, as is dealing with 
other information sources, such as network-based directory services. The 
exchange of short bursts of data between Microsoft handheld users, which 
the development team refers to as a "data squirt," hasn’t been fleshed out 
yet, so the mobile companion work is mainly in the upper-lefthand quadrant 
of the figure on page 5. The important feature of interchange with other 
platforms lies even further out. 


This inward focus makes sense at this time -- mostly. Microsoft's first 
priority is turning Windows into a family of scalable OSes for collaborat- 
ing platforms, from enterprise transaction servers to tvs, pcs and hand- 
helds. Clearly, Microsoft is working with third parties to deliver innova- 
tive applications and services on them. Microsoft is also open to and ac- 
tive in standards discussions, but standards take time and are usually 
based on lessons learned from real systems, anyway. 


Microsoft has complete control over its own suite of offerings. So its 
handheld OS will be designed to synchronize readily with pcs running Win- 
dows, but not with other desktop systems or handhelds, unless those vendors 
write to Microsoft's specs, which assume a specific architecture. 
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The Architecture 


The Microsoft handheld OS is based on an object store that is structurally 
similar to the MAPI message store, and in fact also acts as a message 
store. Synchronization is a basic, built-in capability that offers users 
simple yet powerful collaborative-development features. For example, a 
user could develop an order-entry form for the handheld using Visual Basic 
on a pc. The software objects she creates are then automatically propa- 
gated to her handheld, and can even be registered on the pe network for 
others to see and use. 


Similarly, a departmental programmer can develop a small application, rely- 
ing on the synchronization feature to distribute it to the appropriate 
users’ handhelds. Synchronization is selective, which is essential, since 
the handhelds are likely to be very memory constrained, and communication 
costs will vary widely, from free (docking), to inexpensive (paging), to 
expensive (mobile data radio networks). 


While this architecture is likely to suit a subset of potential users, it 
won't £it many, because it assumes that the handheld’s owner uses the 
built-in object store and is running the corresponding software on her pc. 
(Third parties are welcome to extend the object store with new features, 
which Microsoft encourages, but they can’t swap it out.) Users of handheld 
units will likely want a broader variety of interfaces to their address 
book and calendar than this will offer. Many will also want more autono- 
mous devices. 


Presenting this architecture as the Microsoft solution for handhelds opens 
opportunities for other vendors. If Microsoft presented WinPad as the 
first of a set of handheld Windows platforms (and optimized for a certain 
type of Windows user), the message would be more complete and third-party 
platform opportunities would be less apparent. Also, by designing its sys- 
tems with an inward focus, rather than pushing heavily for inclusive PDI 
standards, Microsoft is ignoring a powerful selling proposition: that the 
handheld is a gateway for interaction with the rest of the world. 


INTELLILINK: BERLITZ FOR PIMS AND POCKET ORGANIZERS 


The lack of formats and protocols for communicating personal and calendar 
information has become big business for New Hampshire-based IntelliLink, 
which offers a translation engine that converts data between pocket elec- 
tronic organizers and most of the major DOS and Windows PIM offerings, 3 
synchronizing their address books and calendars. Though the initial ap- 
plication was for one user uploading new data from a pocket organizer to a 
desktop system, IntelliLink is also useful for migrating data from one PIM 
to another, and for intra-pce communications. It does not support any Mac- 
intosh PIMs, nor does it do person-to-person data squirts. 


3 With the recent release of Version 3, IntelliLink supports Arabesque’s 
Ecco, Lotus Organizer, Polaris’ PackRat, Jensen-Jones’ Commence, Symantec’s 
ACT, Borland’s Sidekick and the basic Windows cardfile and calendar. 
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IntelliLink is moving in many complementary directions: toward network- 
based systems such as WordPerfect Office, which it already supports, and 
Schedule+, which it will support this October; toward new handhelds and 
PDAs such as EO, Newton, Microsoft (WinPad) and General Magic, all of which 
it is working with; and toward wireless communications via RadioMail, which 
will essentially act as the transport for messages (the role LapLink plays 
now with cabled or dialup connections). The wireless work is particularly 
important, since it will allow real-time notification and posting of sched- 
uling events for mobile workers. 


Unlike Traveling Software's LapLink, which compares files’ last-modified 
dates to see which should be copied where, IntelliLink does field-level ex- 
change, with a notification option. That is, if you want to avoid entering 
some records, or if both applications have been updated since the last syn- 
chronization, IntelliLink allows you to step through each entry, skip or 
change any field, then commit it. If both calendars show a lunch appoint- 
ment for next Thursday, you can choose the one you want, make changes to 
it, and store it in your PIM or scheduler. 


LapLink and IntelliLink are complementary and often used together. LapLink 
manages connectivity, IntelliLink the file formats, translations and record 
processing. IntelliLink is co-marketed with most existing pocket organizers 
and palmtop computers, as well as most of the major PIMs on the market, 
which enclose promotional flyers for IntelliLink with their software. 


A little nest egg 


Keith Crozier founded IntelliLink in 1990 to create software that would al- 
low personal organizers such as the Casio BOSS and Sharp Wizard to inter- 
change information with IBM's Current PIM. Then director of Boston Univer- 
sity's Center for Project Management, he began writing the software on 
evenings and weekends, figuring it would be supplemental retirement income. 
Six months later, he quit his post to run IntelliLink full time. Now he 
has 11 employees and funds operations mostly from earnings (he estimates 
1993 revenues will be between $1.5 and $2 million). Crozier spent his ear- 
ly career at IBM and Wang, with a roller-coaster stint in between managing 
oil partnerships. 


Of course, IntelliLink should continue to do quite well if nobody agrees on 
common PDI formats, since everyone will have to license (or write) modules 
for one-to-one translations such as the ones it already offers. If and 
when lower-level elements of his product are supplanted or obsoleted by 
operating-system advances or standards such as PDI, Crozier plans to keep 
moving to higher sources of value, characterized by the SmartMerge recon- 
cillation function IntelliLink has today. With WinPad, for example, syn- 
chronization is a feature of the operating system; IntelliLink’s value is 
in reconciling the data being exchanged. 
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CALENDARING AND SCHEDULING 


Because it is more conversational than exchanging business cards (can you 
meet next Tuesday? no, I’m on deadline, but maybe Wednesday), calendaring 
personal data interchange is significantly more complicated. It requires 
looking up free time, setting tentative meetings and dealing with multiple 
attendees. Worse still, today’s group-calendaring systems work only with 
static desktop computers. People on the move usually print a copy of their 
schedule and authorize an assistant to act as their proxy. When they re- 
turn, they have to reconcile all the meetings booked in the meantime. 


Gotta play with the pocket pals 


Handhelds, especially combined with wireless communications, are essential 
to the long-term success of group calendaring because they will put mobile 
workers on the same footing as those sitting at their pcs. Resolving ques- 
tions right away eliminates a huge amount of downstream activity. 


Calendaring-system software vendors might hope to compete only against each 
other, but that is quickly changing. Many of the vendors we have mentioned 
so far offer calendaring. Newton, the HP pocket computers, EO, Zoomer and 
other handhelds all have built-in schedule minders. And PIM vendors, orig- 
inally focused exclusively on personal productivity, are extending their 
calendar features onto the corporate network. We hope eventually there 
will be open time servers, just as there are open message servers today. 


The group calendaring and scheduling market is large and growing, and may 
be the subject of a future issue of Release 1.0. However, here we focus on 
the standards efforts afoot, emphasizing the role that handheld devices 
play and the effect that Telescript will have. 


As with PIMs, interoperability hasn’t been a big driver for vendors of 
group-calendaring systems. But they have shown more energy and initiative, 
as evidenced from presentations at a recent meeting hosted by the XAPIA. 


The XAPIA asks the right questions 


The X.400 API Association (XAPIA)* recently held an open, one-day workshop 
to assess whether it should get involved in developing common communication 
standards for group calendar/scheduler applications; the answer was "yes." 
While it may seem suspect for a group formed to promote X.400 e-mail mes- 
saging to play the role of unbiased intermediary in an issue that clearly 
has other solutions, the XAPIA has actually proven itself quite honorable. 
The group took less than a year to defuse the MAPI/VIM (read: Microsoft- 
/Lotus) e-mail message-protocol wars, which led to its publishing the Com- 
mon Messaging Calls. 


4 The non-profit XAPIA was formed in 1989 by user and vendor companies to 
promote the availability of specifications for electronic messaging ap- 
plications development. XAPIA‘’s current members include American Express, 
AT&T, Boeing, BT, Bull, DEC, Data Connection, Lotus (ec:Mail), HP, Hughes 
Aircraft, IBM, Isocor, Microsoft, Monsanto, Novell, OSIware, RAM Mobile 
Data, Retix, Soft-Switch and Tandem. Voting membership is $5000 per year; 
associate memberships are $2000. 
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True, KAPIA has an e-mail bias and there were no PIM representatives at the 
workshop, but the Association seems to be the best bet as a forum for PDI 
discussions on calendaring. The standards presented at the workshop are 
likely to influence KAPIA'’s course over the next year. 


One of those efforts was by three calendaring-system vendors that are part 
of the MHS Alliance: Microsystems Software's (CaLANder), Campbell Services’ 
(OnTime) and ON Technology (Meeting Maker). (ON recently merged with Note- 
work, a LAN desktop-message TSR vendor.) Since they share MHS as a trans- 
port, the three companies have already agreed on interchange protocols. 


Necessity, the mother of needed software protocols 


Some interoperability efforts are driven by customer demand. For example, 
an IBM team responded to customers looking to hook production applications 
to IBM’s Time and Place/2 by developing protocols that the company has gen- 
eralized (to avoid an IBM bias) and published as VIC, the Vendor Indepen- 
dent Calendaring specification. IBM is offering VIC to standards commit- 
tees for consideration. 


Proposed by Ric Telford of IBM’s software lab in Westlake, Texas, VIC is a 
calendar-enabling interface API -- it makes applications calendar-aware, as 
VIM does with messaging. For example, when a customer calls a voice- 
response system to report a service problem, the application could use VIG 
to find free time in a field tech’s schedule, then post the service call to 
that schedule. 


Microsoft’s calendaring efforts 


Customers also precipitated some of Microsoft's efforts. At the XAPIA 
meeting, Bill Sornsin, Microsoft's product manager for enterprise messag- 
ing, described Microsoft's efforts to date, which have been mostly inter- 
nally focused. Responding to similar customer requests, Microsoft created 
SPL, the Schedule+ Libraries for Visual Basic and C++, which allow devel- 
opers access to Schedule+ files. 


As a way of moving toward collaboration within XAPIA, Sornsin proposed a 
practical, short-term solution for message-based calendar transactions: ex- 
tending XAPIA’s CMC protocols with five new message types -- request, ac- 
cept, decline, negotiate and cancel a meeting. These messages would carry 
only minimal information needed to describe the appointments. This propos- 
al is less ambitious than VIC, but it covers some of the same ground and 
piggybacks on XAPIA’s success with CMC, which is already built into the 
next version of Windows. 


5 VIC is not an API for calendar-system synchronization or interoperabil- 
ity, or even an API for calendar client software to talk to servers. VIC 
does not specify any user-interface elements and is independent from e-mail 
and directory systems, and specifies 22 functions to manage calendar query 
and info retrieval sessions. 

6 Early WinPad calendaring capabilities will be limited to responding. 
Creating a meeting requires the originator to be able to browse other 
people’s schedules in order to pick a reasonable starting time. WinPad’s 
communications won’t allow for that for some time. 
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What role for Telescript? 


General Magic's Telescript is likely to play a more important role in set- 
ting PDI standards. In part, the market size of the companies that have 
licensed Telescript should force its broad adoption. More importantly, 
though, Telescript is a way for applications (and people) to ask better 
questions when they conduct activity with other entities on the net (just 


‘Scenario: cross-platform calendaring, with ‘standards ee ee 
This is what ‘today’ s seneduring tamoili might be’ like “it it were 


extended to: provide interoperability. “Zoe would like to book a meet- 7 
ing with single Juan e ee ai She looks at her ‘calendar, pick: is 


cipante’ 5 A an edness bot and 
hen Bees a button. a 


hor otrie mee wasn't a to the group poan nera until. ay Zoe? iso 
Pequest. So. ‘she has to say, no, and ask for a new. time. 5 


Juan replies that he will attend, but, “only. if Alice is there. She is 


He also Suggests that Gleo’ r ‘inc ded in the cnseting: 


Zoe reads Juan’, S message and starts the process again: o A 
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what net that is, we leave as an exercise for the reader). The argument is 
compelling. If Telescript doesn’t make it, the same functions will. 


Inspiration hit Jim White, Telescript’s architect, in the late 1980s as he 
and others elaborated elements of the X.400 messaging and X.500 directory- 
services standards. As they refined the protocols, White noticed that they 
might be answering the wrong question. Planning for all permutations was 
leading to a system with very smart (and complex) servers, and very 
specific (and limited) client/server interfaces. Why not instead make the 
questions (and the messages they are carried in) a lot smarter? That would 
balance the system's intelligence between servers and clients. 


Take, for example, two hypothetical calendaring scenarios: one that in- 
cludes new interoperability standards, but no Telescript (opposite), and 
another with Telescript-enabled services (below). 


Telescript is built around Agents and Places. The agents go places, and 
act on their creator’s behalf. Telescript-enabled stationery is smart. 
Messages can include layout hints (portrait or landscape? where are the 
elements?), music or animation (imagine a line of animated greeting cards). 
Automatic RSVP buttons can post meetings to your calendar. Telescript mes- 
sages also have authentication and permission to spend a certain budget on 
their owner's behalf. 


 Telescript: Agent savant 


As. denizens of Tetescript -enabled Sois Zoe, Phil, Juan: e 

Alice have defined software agents that reflect. their preferences andi- 
status, and are authorized do simple negotiations:or spend a little... 
money for approved purposes without consulting their owners directly... 
These agents, inhabit a message center in the so-called network cloud... 
(Zoe and Juan have other agents that hang out in classified-ad mar- 
kets, looking for good deals on antiques and collectibles; Phil.-has 
similar agents looking for parts for his 1954 Vincent Rapide motor- 
cycle; Alice is living a life of voluntary. simplicity and doesn’t 

want anyone: or a TE helping her: spend: money -~ her agent: filters 
hens) mail; Jo i soaz ; a 


To. “compose her. meeting req oe converses with her "Letts: Meet". 
agent, which is already aware of some of her preferences, but needs. 
more details on this particular meeting. This agent was expensive 
(Zoe. manages meetings fora: living), sso it-knows.a lot about meet- . > 
and. asks; about.. alternate times up front in case the first a 
2 also asks who the key participants ALE Pb es: 
ae It. doesn't. put Zoe. through - every. possible = 
combination, ‘though; that would. Þe bothersome and ‘inefficient’ oe? 


Zoe sends her agent. off to rendecyous wih the char agente’ repre- : 
senting other potential participants. Much, perhaps. not all, of the 
negotiating can occur right away, between the agents. Note that 
Zoe's smart: agent can: talk to. other, dumber agents. (as. in real life). 


ebecomes ¢ a + platform for distributed, communicating applications: 
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PHYSICAL LAYER STUFF 


Between the immediate gratification of putting business cards through a 
scanner and watching their contents show up on your screen, and the long- 
term ideal of a canonical PDI format that changes our expectations of elec- 
tronically mediated communications forever, lie many nitty-gritty technical 
issues. 


Some of the thorniest are at the physical layer, and it’s not clear that 
they will work themselves out alone. Technical interoperability is essen- 
tial. For example, a person on a phone call isn’t going to take the time 
and effort to make a separate data connection in order to send her name and 
number to the other person; it has to happen within the existing connec- 
tion. That requires protocols that allow for simultaneous (or at least 
near-realtime) transmission of sounds, data and images over the same lines. 


Too many physical-layer efforts are narrowly focused. People working on 
phone protocols aren't talking to data experts. Wireless is a mess: In- 
door is different from outdoor, voice is separate from data’ and infrared 
is off on its own. ISDN will take ages to roll out, and becomes available 
only on a switch-by-switch basis; ADSI (see below) is underpowered. Some 
clever vendors are trying custom solutions, but they are generally pretty 
expensive and it’s hard to imagine them as ubiquitous, general-purpose 
solutions (see ShareVision, Release 1.0, 12-92). 


It’s not just a matter of transmitting data, either: The intelligent net- 
works are seething with useful control and network-status signals, too. 
Harnessing them will allow vendors to offer much more value. As a simple 
example, common control codes would allow an infrared-equipped General 
Magic machine (or any other compliant device) to drive any similarly 
equipped cellular phone. Forget about smart screen phones with expensive 
LCDs and hard~to-use keyboards; the handheld becomes the directory. 


Link globally, zap locally 


Several connectivity patterns make sense for PDI. At a distance, the tele- 
phone network (enhanced with local-area wireless networks) will share traf- 
fic with e-mail data networks. The phone-system sessions may be voice con- 
nections, modem sessions, or some combination. Phone data sessions will be 


the likely way to synchronize, while exchanging information could happen 
either way. 


Close up, people who want to synchronize files may have portables that 
dock, in which case they will have a robust connection. If docking isn’t 
possible, they will probably prefer infrared links to cables: no plugging, 
no carrying, no forgetting. For simple data beaming (or squirting, or zap- 
ping, or whatever), infrared is hard to beat. It is inexpensive, unregu- 
lated, harmless and usually reliable. 


7 Upcoming digital cellular standards aren't designed to carry data. Even 
CDPD (Cellular Digital Packet Data), the eagerly awaited data-over-analog- 
cellular protocol, won’t let someone who already has a voice session trans- 
mit data at the same time. The caller has to drop the voice call, burst 
the data, then reconnect. 
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Two infrared protocols are particularly noteworthy in the context of PDI: 
HP’s SIR and General Magic's MagicBeam. The two standards are in a tug-of- 
war of their own that echoes the TDMA/CDMA battles in the cellular industry 
(without the public spectacle). Both fall between the simple infrared sig- 
naling that tv remotes and other such devices use and the more complex and 
powerful infrared personal-area networks that Photonics is developing (see 
Release 1.0, 10-92). 


SIR gets some respect 


Hewlett-Packard has been including infrared connectors in many of its pro- 
ducts for several years -- with far more success than the IBM PCjr’s infra- 
red keyboard. Recently HP made the lower-level protocols public as the 
Serial Infrared (SIR) communications interface. The Infrared Data Associa- 
tion (IRDA), originally an HP SIR user’s group, endorsed SIR after evaluat- 
ing other proposals from Sharp and Sony. It would like all vendors to fall 
in and adhere to SIR. The Personal Computer and Communications Association 
(PCCA), which has focused its efforts on adoption of standards that will 
foster growth in the mobile-computing market (e.g., PCMCIA cards, wireless 
modems and infrared links), has likewise endorsed SIR. 


Ken Jacobsen, president of Connexus, a 12-person consultancy he founded in 
1980, is acting as a facilitator and licensing agent for SIR. As the IRDA 
agrees on higher-level protocols for infrared, Connexus will write and li- 
cense SIR drivers. 


SIR has proven itself in the field and is cheap, but it has limitations, 
particularly as transmission speeds and the number of devices sharing air- 
space increase: The signals rapidly interfere with each other. (One con- 
tentlous point is whether interference really matters within a two- to 
three-meter radius.) SIR is also a very low-level spec, and could stall 
because companies have to write too much software to make it work for them. 
The IRDA has formed a committee to define higher-layer protocols, but much 
engineering remains to be done. 


MagicBeam: once more, with symbols 


Frustrated by these Limitations, General Magic developed a standard called 
MagicBeam (the Sony proposal rejected by the IRDA), which treats the in- 
frared spectrum the same way that radio broadcasters treat the radio spec- 
trum (see box, next page) and offers a complete OSI protocol stack. 


MagicBeam was started by Philips NV. Sony developed it further and li- 
censed the optics, modulation and signaling to General Magic, royalty-free. 
General Magic, in turn, fleshed the spec out to a full OSI protocol stack, 
and is licensing it to members of its alliance, which will all use Magic- 
Beam (some will support SIR, too). Other companies can license MagicBeam, 
whose designer and champion is General Magic’s Tony Fadell. His goal is to 
provide a built-in, -seamless end-to-end solution for device manufacturers. 


MagicBeam hardware costs less than $5 (basically a one-chip detector from 
Sony or Motorola); the protocol stack occupies less than 5K of memory (sans 
Telescript, from which MagicBeam is independent). That compares to $3 and 
roughly 2K of code for SIR. Of course, if either one gets very popular, 
those costs should come down. MagicBeam’s power consumption is effectively 
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the same as SIR, but with three times the range. 8 The two protocols aren't 
compatible. A manufacturer could emulate SIR with a MagicBeam system by 
adding a logic block, but SIR can’t do MagicBeam without being MagicBeam. 
For a while, the two protocols are likely to coexist; market forces will 
determine if either one wins. 


Channels over infrared 


MagicBeam is like stereo to previous infrared technologies’ Morse 
Code. That is, tv zappers and HP 95LXes use spikes of infrared light 
(modulated at 40 KHz) that. cut across the whole infrared spectrum to 
indicate the presence of a bit, and no signal to indicate absence. 
MagicBeam uses a constantly modulated carrier signal, and divides the 


spectrum into channels so multiple infrared devices can share the 

same. airspace. The protocol reserves the space under 1 MHz for devi- | 
ces suchas remote controls, then defines data, audio and video bands: 
above that frequency, each of which is further subdivided into chan- 
nels. The theoretical maximum data throughput on a data channel is 
220 Kilobits per second over a three-meter range; prototypes are 

doing 38.4 Kbps now. 


RADISH: DATA OVER YOUR VOICE LINE 


If we want to enable people to hit a key on their telephones that transmits 
their name and number to someone else in computer-readable form, we need a 
protocol for transporting data signals over ordinary phone Lines during an 
analog call. One option is multiplexing voice and data over the same line, 
but so far, that requires hardware that is expensive enough that it proba- 
bly won't be in consumer devices soon. Another option is ISDN, which de- 
pends entirely on telecom carriers upgrading their equipment, and will take 
a long time to roll out (though it is gaining momentum). 


The January issue of Release 1.0 described a third option, Bellcore'’s Ana- 
log Display Services Interface (ADSI). But ADSI, while useful, is func- 
tionally impoverished since it was designed so specifically for screen 
phones. It runs at a mere 1200 baud, transmits only text in half-duplex 
mode and is asymmetric: A service provider (such as a bank) sends full AS- 
CII characters and control codes to the screen phone, which replies only in 
touch tones -- ADSI’s designers assumed that a caller has only a phone 
keypad. (With upcoming PDAs, callers will have RISC processors and DSPs!) 


VoiceView, a protocol that Boulder-based Radish Communications created to 

send data and images between users having telephone conversations enhanced 
with Radish terminals, may be a better option for the near term. Radish’s 
founders, Dick Davis and Theresa Szczurek, originally worked on ISDN at 


8 SIR has a range of 1 meter that can stretch to 2 by shifting to dif- 
ferent infrared frequencies. It can operate at 3 volts, but all current 
implementations run at 5. MagicBeam covers 3 meters and the equipment 
available so far operates at 3V. 
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Bell Labs. After leaving the Labs in 1990, Davis called a travel agent, 
who read information off his screen while Davis took copious notes and grew 
increasingly frustrated. So Davis resolved to create a better way of con- 
ducting business over the phone that could benefit from shared displays of 
data, such as conversations with a stock broker or travel agent. The com- 
pany name is a play on Davis’ initials (Richard A. Davis). 


"The more you can pack into a call while you're having the 
call, the better.” -- Dick Davis, Radish 


Radish users can send each other data files quickly (though they can’t si- 
multaneously edit them on-screen, a desirable feature). In fact, one caller 
can upload a file or several screens of information to another Radish user's 
voicemail. When the second user gets the message, she can have her Radish 
system detect and interpret it. Voicemail acts as a tape recorder. 


VoiceView inside? 


Radish currently sells a full line of hardware and software products, in- 
cluding desktop terminal devices called VoiceView Sets for people without 
pes, the modem-like VoiceView Bridge for those who have pcs and the Voice- 
View protocol itself. Fortunately, Davis recognizes that the hardware is 
not the point, and is working to turn the VoiceView protocol into a lingua 
franca for sending data over the phone by licensing it broadly. In fact, he 
has closed enough business that by next year he expects many devices to 
embed VoiceView capabilities, from modems to PBXes, voice-response and -mail 
systems, smart phones and PDAs. With DSPs becoming more common on pe plat- 
forms, Davis expects a software-only version to be popular, too. That seems 
to be the most compelling option, but Radish will continue manufacturing 
hardware as long as it is profitable and others don't make better competi- 
tive products. 


VoiceView is a proprietary, inexpensive, reasonably quick (9600-baud, plus 
compression), two-way voice and data protocol that allows devices that use 
it to send or swap information during a voice call. Radish is making the 
technology available through licensing, roughly similar to the way Microcom 
licenses MNP, the modem data-compression protocol. During a call, the voice 
part of the session is completely normal, and remains analog. When the user 
invokes a data message, VoiceView mutes the voice channel briefly and takes 
over the full connection bandwidth. It is optimized to synchronize, trans- 
mit and error-check quickly: A screenful of text takes under three seconds. 


VoiceView is used only when it is needed. Placing and managing a call re- 
mains unchanged. This means potential equipment cost savings, because PBXes 
with VoiceView processors attached could serve many simultaneous callers, 
few of whom would need VoiceView services at the same time. (In fact, some 
early PBX implementations use the PBX conferencing feature to bring in 
VoiceView features.) This means a circuit- and board-level vendor such as 
Dialogic or Natural MicroSystems could make an attractive business of sell- 
ing VoiceView adjunct systems. 
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VoiceView is not for all applications. It is designed for sending bursts of 
data (e.g., a screen shot, a file, my address info), not constant control 
signals such as cursor movements in a word processor or interactive game. 
Unlike ADSI, which can detect phone-system control commands such as busy 
signals or calling-card approval ("bong") tones, VoiceView assumes that a 
call is already established, with one exception: It will auto-answer a call 
and receive information. 


COMING SOON 


The contractual society. 

New! Improved! Multimedia! 

Research on learning. 

The future of the local loop. 
Constraint-based reasoning. 

Pen stuff. 

And much more... (If you know of any 
good examples of the categories listed 


above, please let us know.) | 
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Release 1.0 is published 12 times a year by EDventure Holdings, 104 Fifth 
Ave., New York, NY 10011-6987; (212) 924-8800. It covers pes, software, 
computer-telephone integration, groupware, text management, connectivity, 
messaging, wireless communications, artificial intelligence and intellectual 
property law. A companion publication, Rel-EAST, covers emerging technology 
markets in Central Europe and the former Soviet units. Editor: Esther 
Dyson; publisher: Daphne Kis; contributing editor: Jerry Michalski; cir- 
culation & fulfillment manager: Robyn Sturm; executive secretary: Denise 
DuBois; editorial & marketing communications consultant: William M. Kutik. 
Copyright 1993, EDventure Holdings Inc. All rights reserved. No material 
in this publication may be reproduced without written permission; however, 
we gladly arrange for reprints or bulk purchases. Subscriptions cost $495 
per year, $575 overseas. 
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RESOURCES & PHONE NUMBERS? 


James Joaquin, Apple (Newton), (408) 974-8458; fax, (408) 257-8120; 
joaquinl@applelink.apple.com 

Yefim Schukin, Cognitive Technology, (415) 925-2323; fax, (415) 461-4010; 
yschukin@well.af.ca.us 

Ken Jacobsen, Connexus, (510) 490-7095; fax, (510) 656-2195 

Jonathan Stern, Corex Technologies, (617) 277-5344; fax, (617) 277-5069 

Roland Alden, EO, (415) 358-3022; fax, 345-9833; roland_alden@go.com 

Randy Stock, EO, (415) 903-8122; fax, (415) 903-8190; randys@eoc.com 

Tony Fadell, General Magic, (415) 966-6258; fax, (415) 965-9424; 
tony. fadell@applelink.apple.com 

George Fan, General Magic, (415) 966-6283; fax, (415) 965-1830; 
george fan@genmagic.com 

Jim White, General Magic, (415) 966-6755; fax, (415) 965-9424; 
jim_white@genmagic.com 

Ric Telford, IBM, (817) 962-5689; fax, (817) 962-6730; rtelford@vnet.ibm.com 

Keith Crozier, IntelliLink, (603) 888-0666; fax, (603) 888-9817; 
74040.732@compuserve.com 

Ed Owens, Lotus/cc:Mail (XAPIA), (415) 335-6646; fax, (415) 960-0840; 
eowens@ccmail.com 

Peter Bergler, Microsoft, (206) 936-6550; fax, (206) 936-2491 

Bill Sornsin, Microsoft, (206) 936-7003; fax, (206) 936-7329 

Richard Davis, Radish Communications Systems, (303) 499-3592; fax, (303) 
443-1659 

Andy Seybold, Seybold Outlook on Personal Computing (PCCA), (408) 338-7701; 
fax, (408) 338-7806; seybold@radiomail.net 

Mark Eppley, Traveling Software, (206) 483-8088; fax, (206) 487-1284; 
mark@bothell.travsoft.com 


9 This list was compiled in Arabesque’s Ecco, then exported (with a set- 
ting we named "Resources" so we can use it next time) in comma-delimited 
format to XyWrite, where we took out quotation marks and notes (unexpected- 
ly exported), added boldface and "; fax". Unfortunately, we had to type 
all the information into Ecco. Alas, if this were only automated.... 
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RELEASE 1.0 CALENDAR 


September 27-29 Messaging forum - San Francisco. Sponsor: Creative Networks. 
Call Nina Burns, (415) 326-9926; fax, (415) 326-4014. 

September 28-29 Electronic Books 1993 - New York City. Sponsored by Meckler. 
With Bob Stein, Voyager; Morton David, Franklin Electronic 
Publishers; Gaston Bastiaens, Apple. Call Alan Meckler, (800) 
635-5537 or (203) 226-6967; fax, (203) 454-5840. 

Sept 26-Oct 1 OOPSLA °93 - Washington, DC. Sponsored by ACM. Call Carole 
Mann, (407) 628-3602. 

September 29-30 @Defining the electronic consumer - New York City. Sponsor: 
Jupiter, Arlen Communications and Telecom Publishing. Call 
Joshua Harris, (212) 941-9252; fax, (212) 941-7376. 

October 3-6 Council of Logistics Management annual conference - Washing- 
ton, DC. Sponsor: Council of Logistics Management. Efficiency 
is next to godliness: Content software for logistics. Call 
David Tarr, (708) 574-0985; fax, (708) 574-0989. 


October 4-7 HelpDoc '93 - Wakefield, MA. Sponsored by ServiceWare. Call 
Jeff Pepper, (412) 826-1158; fax, (412) 826-0577. 

October 5-6 PenTech "93 - London. Sponsor: Business Seminars Internation- 
al. Call Lisa Bilby, 44 (71) 490-3774; fax, 44 (71) 490-2296. 

October 5-7 NetWorld 93 Dallas - Dallas. Sponsored by Bruno Blenheim. 


Gall Annie Scully, (201) 346-1400 or (800) 829-3976; fax, 
(201) 346-1532. 

October 5-8 Sigdoc "93 - Ontario. Sponsored by ACM. Call Pamela Scott, 
(212) 869-7440; fax, (212) 944-1318. 

October 10-13 *kEast-West High-Tech Forum - Bled/Ljubljana, Slovenia. 
Sponsor: EDventure Holdings. The fourth annual Forum for 
emerging computer and data communications markets in Central 
Europe and the CIS, for vendors and value-adders. With a spe- 
cial focus on systems integration and databases as a platform 
for market and product development. Come discover new markets 
that aren’t yet saturated, and new companies that aren’t yet 
jaded. Call Daphne Kis, (212) 924-8800; fax, (212) 924-0240; 
e-mail, MCI 511-3763. 

October 10-13 SPA Fall symposium - Chicago. Sponsor: Software Publishers 
Ass'n. Gall Karen Johnson, (202) 452-1600; fax, (202) 223- 
8756. 

October 12-14 Technology seminar - Baltimore. Sponsor: Alex. Brown & Sons. 
For investors. With Mort Meyerson, Perot Systems. Call Kim- 
berley Lynne, (410) 783-3240. 

October 14-16 Molecular Nanotechnology - Palo Alto. Sponsor: Foresight In- 
stitute. Call Jane Nikkel, (415) 948-5830; fax, (415) 324- 
2497. 

October 14-16 Applications of distributed & graphical simulation - Aber- 
deen, Scotland. Sponsor: University of Aberdeen Department of 
Engineering. Contact: Gorry Fairhurst, 44 (224) 27-2201; fax, 
44 (224) 27-2497; e-mail, asu@uk.ac.abdn.erg. 

October 17-20 EDUCOM '93 - Cincinnati. The edcuation community gathers. 
Call Donna Leggett, (202) 872-4200. 
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OS/2 Professional Interchange - Palm Springs. Sponsor: OS/2 
Professional Magazine. Call Karen Thomas, (516) 549-7575; 
fax, (516) 549-1129. 

ITAA convention & global congress - Washington, DC. Changing 
market dynamics for information services. Sponsor: Informa- 
tion Industry Association., Call Barbara Munder, (202) 639- 
8262; fax, (202) 638-4403, 

Microprocessor Forum - San Francisco. Sponsor: MicroDesign 
Resources. The central chip conference. Call Michael Slater, 
(707) 824-4004; fax, (707) 823-0504. 

Virtual Reality Systems '93 - New York City. Sponsor: SIG- 
Advanced Applications. Call Stan Goldstein, (212) 717-1318; 
fax, (212) 861-0588. 

@Fourth WINLAB workshop on third generation wireless informa- 
tion networks - East Brunswick, NJ. Sponsored by Rutgers Uni- 
versity. Call Noreen DeCarlo, (908) 932-5954; fax, (908) 932- 
3693. 

PC EXPO - Chicago. Sponsor: Bruno Blenheim. Call Annie Scul- 
ly, (201) 346-1400 or (800) 829-3976; fax, (201) 346-1532. 
Media summit '93 - New York City. Sponsored by Intermedia. 
Call Jon Leibowitz, (203) 352-8254. 

EMA's fall membership meeting - Tucson. Sponsored by the 
Electronic Mail Association. Call (7030 875-8620; FAX, (703) 
522-0241, 

Seybold San Francisco - San Francisco. Sponsored by Seybold 
Seminars. Call Beth Sadler or Kevin Howard, (310) 457-5850; 
fax, (310) 457-4704. 

ITAA management conference ~ Seattle. Sponsored by Informa- 
tion Technology Association of America. Call Valerie Czuszak, 
(703) 284-5350; fax, (703) 525-2279. 

The Seybold executive forum: Bringing enterprise systems into 
the "90s (& beyond) - Hancock, MA. Sponsored by Patricia 
Seybold Group. Call Ronnie Marshak, (617) 742-5200; fax, 
(617) 742-1028. 

INTEROP 93 - Paris. The mother of all networking conferences, 
now global. Sponsor: Interop Europe. Contact: Carinne Prop- 
per, 33 (1) 4639-5656; fax, 33 (1) 4639-5699. 

Common desktop environment developers conference - San Jose. 
Sponsored by the UniForum Association. Call Richard Jaross, 
(800) 225-4698. 

Information and Knowledge - Washington, DC. Sponsor: ACM. 
Call Pamela Scott, (212) 869-7440; fax, (212) 944-1318. 
EuroComNet 93 - Amsterdam, The Netherlands. Co-sponsored by 
IDG World Expo and RAI Amsterdam. Call Lisa Judd, (508) 879- 
6700; fax, (508) 872-8237; Rob den Hertog, 31 (20) 549-1212; 
fax, 31 (20) 646-4469, 

InterTainment "93 - Santa Monica. Sponsored by Alexander & 
Associates. Call Sally Plourde, (212) 684-2333, 


Please let us know about events we should include. -- Denise DuBois 


*Events Esther plans to attend. 
@Events Jerry plans to attend. 
Lack of a symbol is no indication of lack of merit. 
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